20 针对规范修订版 2.1 的更新（Updates for Spec Revision 2.1）

上一章

上一章描述了 PCI Express 热插拔模型。同时，针对所有支持热插拔功能的设备和外形规格，也定义了一套标准使用模型。对于热插拔卡而言，功耗同样是一个关键问题：在系统运行期间添加新卡时，必须确保其功耗需求不超过系统能够提供的上限。因此，需要一种机制在允许设备运行前查询其功耗需求，功耗预算寄存器正是为此而设。

本章

本章描述 PCIe 规范 2.1 修订版中新增的变更与特性。其中一部分主题，例如与电源管理相关的内容，已在其他章节中阐述；而其余主题在逻辑上没有更合适的归属。最终，将这些内容集中整合至同一章节，既能确保全面覆盖，也有助于明确哪些内容属于新特性。

下一章

下一节是本书附录，涵盖以下主题：使用力科（LeCroy）工具调试 PCI Express 流量、PCI Express 架构的市场与应用、利用 PCI Express 技术实现智能适配器与多主机系统、对锁定机制的传统支持以及本书术语表。

20.1 PCIe 规范 2.1 修订版变更

PCIe 规范 2.1 修订版引入了几项变更，旨在提升性能或改善运行特性。该版本没有增加新的数据速率，因此被视为一次增量修订。这些修改大致可分为四个改进领域：系统冗余、性能、电源管理和配置。

20.2 系统冗余改进：多播

多播（Multicast/Multi-casting）能力允许一个已发布写请求 TLP（Posted Write TLP）同时路由到多个目的地，从而实现数据冗余副本的自动复制，或支持多显示头图形等功能。如图 20-1 所示，源自一个端点的 TLP 可以仅根据其地址被路由到多个目的地。在该示例中，数据被发送到视频端口进行显示，同时冗余副本会自动路由到存储设备。当然，还有其他方式也能支持类似功能，但这种机制在链路使用效率方面非常高，因为它不需要接收方再把数据包重新发送到次要位置。

图 20-1：多播系统示例

该机制仅支持已发布的、基于地址路由的请求，例如内存写入。这类请求包含待传输的数据，以及可被解码以指示哪些端口应接收该数据的地址。非已发布请求即使其地址落在多播地址范围内，也不会被视为多播请求，而是像往常一样作为单播 TLP 处理。

配置多播操作时，需要为每个参与其中的路由元件和功能编程一个新的寄存器块，称为多播能力结构（Multicast Capability Structure）。如图 20-2 所示，该结构定义了多播地址以及多播组编号（MCG，Multicast Group Number），用于说明某个功能是否应发送或接收传入 TLP 的副本，或者某个端口是否应转发这些副本。下面将逐一介绍这些寄存器，并讨论它们如何在系统中用于建立多播操作。

图 20-2：多播能力寄存器

20.2.1 多播能力寄存器

图中顶部的能力头寄存器包含能力 ID 0012h、4 位版本号，以及指向寄存器链表中下一个能力结构的指针。

20.2.1.1 多播能力

该寄存器如图 20-3 所示，包含多个字段。其中，MC_Max_Group 值定义了该功能被设计为支持的多播组数量减 1。因此，当该值为 0 时，表示支持 1 个多播组。MC_Window_Size_Requested 字段仅对端点有效，在交换机和根端口中为保留字段，用于表示端点为多播窗口所请求的地址空间大小，其编码含义为 2 的幂。

图 20-3：多播能力寄存器

最后，位 15 指示该功能在转发 TLP 时，如果因为地址变更导致原 ECRC 失效，是否支持重新生成 ECRC 值。关于此功能的更多细节，请参见后文“叠加示例”一节。

20.2.1.2 多播控制

该寄存器如图 20-4 所示，包含 MC_Num_Group 字段。该字段由软件编程，用于配置本功能实际使用的多播组数量减 1。默认值为 0。规范指出，如果软件在此处编程的值大于 MC_Max_Group 寄存器定义的最大值，将导致未定义行为。MC_Enable 位用于启用该组件的多播机制。

图 20-4：多播控制寄存器

20.2.1.3 多播基地址

多播基地址寄存器如图 20-5 所示，包含该组件多播地址范围的 64 位起始地址。MC_Index_Position 字段指示在地址中查找多播组编号（MCG）的位置。当传入 TLP 的地址落入以该基地址为起点的多播地址范围内时，逻辑电路会按照 MC_Index_Position 指定的位置进入地址字段，并将后续若干位（最多 6 位，因此最多支持 64 个组）解释为该 TLP 的 MCG 编号。随后，MCG 编号将决定端口是否需要转发该 TLP 的副本。

图 20-5：多播基地址寄存器

图 20-6 展示了在地址中定位 MCG 的示例。此处 MC_Index_Position 值为 24，因此 MCG 位于地址中由该位置指示的若干位上。值得注意的是，由于基地址未定义地址的低 12 位，因此 MC_Index_Position 必须大于等于 12 才有效。如果该值小于 12 且 MC_Enable 位被置位，则组件行为未定义。

图 20-6：多播组编号位置

20.2.1.4 多播接收

MC_Receive 是一个 64 位寄存器，本质上是一个位向量，用于指示此功能应接收哪些 MCG 的副本，或者此端口应转发哪些 MCG 的副本。例如，如果 MCG 值为 47，且该寄存器中第 47 位被置位，则该功能应接收此副本，或该端口应转发此副本。

20.2.1.5 多播全部阻止

MC_Block_All 是一个 64 位寄存器，用于指示端点功能被阻止发送哪些 MCG，或者交换机、根端口被阻止转发哪些 MCG。例如，可以在交换机或根端口中编程该寄存器，以防止其将多播 TLP 转发给无法理解这些 TLP 的端点。被阻止的 TLP 被视为错误条件，下一小节将说明该错误如何处理。

20.2.1.6 MC 阻止未翻译

MC_Block_Untranslated 也是一个 64 位寄存器，其含义和用途与 MC_Block_All 寄存器几乎相同，但它不适用于 AT 头部字段显示为“已翻译”的 TLP。该机制可用于建立一个受保护的多播窗口，使其只能接收已翻译地址的 TLP。

如果由于这两个阻止寄存器中任一寄存器的设置而导致 TLP 被阻止，则该 TLP 将作为 MC Blocked TLP 处理：TLP 被丢弃，并且端口或功能会记录该错误并将其作为错误发出信号。记录错误时，需要在其状态寄存器或辅助状态寄存器中设置相应的“目标终止信号”（Signaled Target Abort）位。不过，这些信息对定位故障的帮助有限，因此规范强烈建议具备多播能力的功能实现高级错误报告（AER）寄存器，以便隔离和诊断故障。

规范指出，所有实现多播能力寄存器的功能都必须包含该寄存器。不过，如果端点功能未实现地址转换服务（ATS）寄存器，设计人员可以选择将这些位设为保留位。

20.2.2 多播示例

下面通过一个示例说明如何使用这些寄存器建立多播环境。首先为相关寄存器设置如下值：

• MC_Base_Address = 2GB，表示多播范围的起始地址。
• MC_Max_Group = 7，表示该设计最多支持 8 个多播窗口。
• MC_Window_Size_Requested = 10，表示端点请求的窗口大小为 2^10，即 1 KB。
• MC_Index_Position = 12，表示每个窗口的实际大小为 2^12，即 4 KB。
• MC_Num_Group = 5，表示软件只配置了可用多播窗口中的 6 个。

基于这些寄存器设置，图 20-7 展示了最终结果。多播窗口范围从 2 GB 开始，硬件最多可覆盖 8 个窗口；但软件只启用了 6 个窗口，因此实际多播地址范围为 2GB 到 2GB + 2^12 × 6，也就是 2GB 到 2GB + 24KB。所有窗口大小相同，并与 MCG 一一对应：MCG 0 为第一个窗口，MCG 1 为下一个窗口，以此类推。

图 20-7：多播地址示例

20.2.3 MC 叠加 BAR

最后一组寄存器是实现多播功能的交换机和根端口所必需的，但端点设备不实现这些寄存器。该 BAR 的设计动机是支持两种特殊情况。第一，即使端点设备本身并不是为多播设计的，端口仍可在多播窗口命中时向下游转发 TLP。第二，端口可将多播 TLP 向上游转发至系统内存。这两种情况都是通过将请求地址的一部分替换为目标能够识别的地址来实现的。这样，即使某个组件中的单个 BAR 并不是为多播能力设计的，也可以同时作为单播写入和多播写入的目标。

如图 20-8 所示，该寄存器块包含一个将叠加到传出 TLP 上的地址，以及一个 6 位的叠加大小指示符。这里所说的大小，是指原始 64 位地址中将被保留的位数，其余位将由叠加 BAR 中的地址位替换。规范中至少有一处错误地将其称为“字节大小”，但其他位置已明确说明它是位数。需要注意的是，叠加大小值必须为 6 或更大，叠加操作才会启用。如果该值为 5 或更小，则不会发生叠加，地址保持不变。

图 20-8：多播叠加 BAR

20.2.4 叠加示例

现在考虑需要地址叠加的情况，如图 20-9 所示。此时，待转发 TLP 的地址 ABCD_BEEFh 落在已定义的多播范围内，也就是发生了多播命中；同时，出口端口已在叠加 BAR 中配置了有效值。

叠加操作会引发前文在多播能力寄存器中提到的 ECRC 异常情况。如果被叠加修改地址的 TLP 包含 ECRC，则该 ECRC 值会因为地址变化而失效。交换机和根端口可以选择支持基于新地址重新生成 ECRC，使其在转发后仍然能够发挥校验作用。如果路由代理不支持 ECRC 重新生成，则直接丢弃 ECRC，并将 TLP 头部中的 TD 位强制清零，以避免产生混淆。

ECRC 重新生成还可能带来一个潜在问题：如果传入 TLP 原本已经存在错误，但路由代理因为地址被修改而重新生成了 ECRC，就可能无意中掩盖原始错误。为避免这种情况，路由代理必须先验证原始 ECRC。如果检测到错误，则必须在传出 TLP 上强制生成错误 ECRC，方法是在追加 ECRC 前反转计算出的 ECRC 值，以确保目标端仍能识别该错误条件。

图 20-9：叠加示例

20.2.5 路由多播 TLP

当交换机或根端口检测到 MC 命中，即地址落入 MC 范围时，正常路由会被暂停。逻辑从地址中提取 MCG，并将其与所有端口的 MC_Receive 寄存器进行比较，以确定哪些端口应转发该 TLP 的副本。对应 MC_Receive 寄存器位已置位的端口将转发 TLP 副本，除非其对应的 MC 阻塞寄存器位也已置位。如果没有任何端口转发该 TLP，且没有任何功能消耗它，则该 TLP 会被静默丢弃。为防止形成环路，TLP 绝不会从其入口端口被转发回去，ACS 场景下可能存在例外。

端点会提取 MCG 并与自身的 MC_Receive 寄存器比较。如果不匹配，该 TLP 将被静默丢弃。如果端点不支持多播功能，则会将该 TLP 当作普通地址的 TLP 处理。

20.2.6 拥塞避免

使用多播会按照多播流量所占比例增加系统流量，从而带来数据包拥塞风险。为避免产生背压，多播目标应设计为能够“全速”接收多播流量，即以最小延迟接收。为避免链路过载，多播发起方应限制数据包注入速率。系统设计者需要谨慎选择组件来应对这一问题，例如选择缓冲区容量足以处理预期流量的交换机和根端口，以及能够足够快地接收传入多播数据包的端点设备，以避免故障。

20.3 性能改进

系统性能通过新增四项功能得到提升：

1. 使用 AtomicOps 替代传统事务锁定机制。
2. 使用 TLP 处理提示，允许软件建议缓存选项。
3. 使用基于 ID 的排序，以避免不必要的延迟。
4. 使用替代路由 ID 解释，以增加设备中可用的功能数量。

20.3.1 原子操作

共享资源或相互通信的处理器有时需要对系统资源进行不可中断的、即“原子性”的访问，以执行测试并设置信号量等操作。在并行处理器总线上，这是通过断言 Lock 引脚来锁定总线实现的，直到发起方完成整个序列（先读后写）。在此期间，其他处理器不允许在总线上发起事务。PCI 包含一个 Locked 引脚，用于在 PCI 总线上应用与处理器总线相同的模型，从而使该协议能够与外围设备一起使用。

该模型虽然可用，但在共享处理器总线上速度较慢，在进入 PCI 总线后性能更差。这也是 PCIe 将其使用范围限制在传统设备上的原因之一。然而，随着图形协处理器和计算加速器等共享处理技术在现代 PC 中越来越常见，这一问题再次凸显，因为不同计算引擎需要能够共享一种原子协议。PCIe 对该问题的解决方式，是引入三个新命令。每个命令都能在目标设备内部原子性地执行一系列操作，而无需在接口上执行一系列不可中断的独立命令。这些新命令被称为 AtomicOps，包括：

1. FetchAdd（Fetch and Add，读取并相加）：该请求包含一个“加数”值。它读取目标位置，将“加数”值与目标值相加，将结果存回目标位置，并返回目标位置的原始值。该功能可用于原子性地更新统计计数器。
2. Swap（Unconditional Swap，无条件交换）：该请求包含一个“交换”值。它读取目标位置，将“交换”值写入该位置，并返回原始目标值。这对于原子性地读取并清除计数器可能很有用。
3. CAS（Compare and Swap，比较并交换）：该请求同时包含一个“比较”值和一个“交换”值。它读取目标位置，将其与“比较”值进行比较；如果两者相等，则写入“交换”值。最后，它返回目标位置的原始值。这可作为管理信号量的“测试并设置”机制使用。

端点（Endpoint）和根端口（Root Port）都可以选择性地作为 AtomicOp 请求者（AtomicOp Requester）和完成者（AtomicOp Completer）。这看起来可能有些出人意料，因为至少在 PC 中，这类事务通常只由中央处理器发起。但现代系统可能包含作为协处理器运行的端点，此时它需要能够使用 AtomicOps 才能正确处理相关协议。

三种命令都支持 32 位和 64 位操作数，而 CAS 还额外支持 128 位操作数。实际使用的操作数大小将在 TLP 头部的 Length 字段中给出。具备点对点访问能力的路由元件，例如交换端口和根端口，需要支持 AtomicOp 路由能力，才能识别并转发这些请求。

一个自然产生的问题是：系统中的根复合体如何根据处理器活动生成这些新命令？因为处理器总线上可能没有与之直接对应的命令。规范提出了两种方法。第一，根复合体可以被设计为识别特定的处理器活动，并将其解释为需要“导出”一个 PCIe AtomicOp。第二，可以使用类似传统配置访问的基于寄存器的方法。在这种情况下，一个寄存器可以给出目标地址，另一个寄存器指定应生成的命令，两者结合即可生成请求。

AtomicOp 完成者可通过设备能力 2 寄存器（Device Capabilities 2 Register）中的三个新位来识别，如图 20-10 所示。该寄存器的位 6 还用于标识路由元件是否支持 AtomicOps 路由。

传统 PCI 当然不理解 AtomicOps，也没有直接方法将其转换为 PCI 命令。因此，PCIe 到 PCI 桥接器不支持 AtomicOps。如果该总线上需要原子访问，则必须使用传统的锁定协议实现。规范指出，锁定事务和 AtomicOps 可以在同一平台上同时运行。

图 20-10：设备能力 2 寄存器

20.3.2 TPH（TLP 处理提示）

为指向内存空间的 TLP 添加系统处理提示，可以改善延迟和流量拥塞。规范将这种特殊处理描述为：提供一项信息，指示系统中多个可能缓存位置中，哪一个最适合保存该 TLP 的临时副本。规范指出，由于 TPH 描述的用途与缓存相关，因此通常不建议将其用于指向不可预取内存空间的 TLP。如果确实需要这种用法，则必须以某种方式保证缓存这些 TLP 不会产生不良副作用。

20.3.2.1 TPH 示例

设备写入，主机读取。 为了说明 TPH 的动机，请参考图 20-11 所示的示例。在该示例中，端点将数据写入内存，供 CPU 后续使用。流程如下：

1. 首先，端点发送一个内存写入 TLP，其中包含映射到系统内存的地址。该数据包被路由到根复合体（RC）。
2. RC 识别出这是一次对可缓存内存空间的访问，于是在窥探 CPU 缓存时暂停其前进过程。这可能导致 CPU 执行一次写回周期，以便在事务继续前更新系统内存，如步骤 2a 所示。
3. 一旦所有写回操作完成，RC 允许该写入更新系统内存。
4. 在某个时刻，端点通知 CPU 数据已交付。
5. 最后，CPU 从内存中取回数据，完成该序列。

图 20-11：TPH 示例

该序列可以正常工作，但如果在系统中增加中间缓存，就有机会提升性能。为说明这一点，请参考图 20-12 所示的示例。从端点角度看，操作流程相同，但系统处理方式有所不同。具体步骤如下：

1. 端点执行相同的内存写入操作，但这一次包含 TPH 位。该写入仍然像之前一样由交换机转发至 RC。
2. RC 理解到，这次内存访问仍然必须像之前一样对 CPU 进行窥探。然而，窥探处理完成后，TPH 位告诉 RC，应将该 TLP 存入中间缓存，而不是直接写入系统内存。
3. 端点通知 CPU 数据项已送达。
4. CPU 从指定地址读取数据，但此时数据已在中间缓存中找到，因此请求不需要访问系统内存。这带来了缓存设计的常规收益：更快的访问速度以及更低的系统内存流量。

这是一个简单的设备写入到主机读取（DWHR，Device Write to Host Read）示例，用于说明这一概念。不难想象，在拓扑更复杂的系统中，还可以在交换机或其他位置放置更多缓存，从而为其他目标带来同样的优势。

图 20-12：使用系统缓存的 TPH 示例

主机写入，设备读取。 为说明相反方向的概念，即主机写入到设备读取（HWDR，Host Write to Device Read），请参考图 20-13 所示的示例。在此示例中，CPU 在第一步发起一次内存写入，其地址指向 PCIe 端点。该数据包包含 TPH 位，告知 RC 应将其存储在目标设备附近的中间缓存中，而不是像前一个示例那样存储在 RC 附近的缓存中。在此场景下，交换机内置的缓存可以满足该需求。随后，TLP 在第二步被转发至目标端点。当数据更新频率较低但端点频繁读取时，此模型尤其有利。这样，原本需要访问系统内存的多次内存读取操作可以由缓存处理，从而减轻从交换机到 RC 的链路以及内存访问路径的负载。

图 20-13：面向端点的 TLP 的 TPH 使用方式

设备到设备。 最后一个示例如图 20-14 所示，其中两个端点通过一个共享内存位置相互通信，该共享内存位置由 TPH 位引导到中间缓存。这种模式称为设备读/写到设备读/写（DD，Device Read/Write to Device Read/Write）。在该场景中，两个设备可能更新不同的位置，并需要将这些位置作为“主要用于读取”的数据来处理；也可能是一个端点更新另一个端点需要多次读取的数据。两种情况下，使用中间缓存都可以提升系统性能。

图 20-14：端点间的 TPH 使用

20.3.2.2 TPH 头部位

TLP 头部中的若干位描述了提示信息的使用方式。首先，如图 20-15 顶部中间所示，TH（TLP Hints）位表示该 TLP 是否使用可选的 TPH 位。当 TH 置位时，PH（Processing Hint）位提供下一层提示信息。

图 20-15：TPH 头部比特位

当 TH 位被置位时，PH 位会取代地址字段中原本保留的两个最低有效位（LSB）。对于 32 位地址，这些位是字节 11 的 [1:0]；对于图中所示的 64 位地址，则是字节 15 的 [1:0]。PH 编码如表 20-1 所示。这些提示由请求者基于其对数据访问模式的了解来提供，而这些信息对完成者来说很难自行推断。

表 20-1：PH 编码表

下一层信息是转向标签字节（Steering Tag，ST），它提供系统特定信息，用于指示缓存此 TLP 的最佳位置。有趣的是，该字节在头部中的位置取决于请求类型。对于已发布内存写入，Tag 字段会被重新用作 Steering Tag，因为不会返回完成报文，所以原本的 Tag 并不需要。对于内存读请求，两个字节使能字段会被重新用作 Steering Tag，因为可预取读取不需要字节使能。其具体含义依赖实现，但这些位必须能够唯一标识系统中期望使用的缓存位置。

规范描述了两种 TPH 格式。第一种格式为基线 TPH（Baseline TPH），其提示信息包括 TH + PH + 8-bit Steering Tag，所有提供 TPH 的请求都必须支持该格式。第二种格式使用 TLP 前缀来扩展 Steering Tag，详情见后文“TLP 前缀”。

20.3.2.3 转向标签

这些值由软件编程到表中，以便在正常运行期间使用。规范建议将该表放在 TPH 请求者能力结构中，如图 20-16 所示；但也可以将其构建在 MSI-X 表中。对于给定功能，只能使用这两种表位置中的一种。表的位置由请求者能力寄存器中的 ST Table Location 字段 [10:9] 给出，如图 20-17 所示。该 2 位字段的编码见表 20-2。

图 20-16：TPH 请求者能力结构

图 20-17：TPH 能力与控制寄存器

表 20-2：ST 表位置编码

请求者能力寄存器在位 [26:16] 中列出 ST 表中的条目数量。每个表项宽度为 2 字节。图 20-18 展示了在 TPH 能力寄存器集中实现的 ST 表，其中条目 0 被高亮显示。请求者能力寄存器还通过最低 3 位描述请求者支持哪些 ST 模式：

• 无 ST（No ST）：使用全 0 作为 ST 位。当 TPH 请求者控制寄存器的 ST Mode Select 字段值为 000b 时选择此模式。
• 中断向量（Interrupt Vector）：使用中断向量号作为进入表的偏移量，意味着这些值包含在 MSI-X 表中。ST Mode Select 值为 001b。
• 设备特定（Device-Specific）：使用设备特定方法在 TPH 能力结构中的 ST 表内确定偏移，因为 ST 值位于该表中。这是规范推荐的实现方式，不过某个具体请求如何关联到特定 ST 表项不在规范范围内。ST Mode Select 值为 010b。
• 其他所有 ST Mode Select 编码均保留供未来使用。

图 20-18：TPH 能力 ST 表

20.3.2.4 TLP 前缀

如果需要，可以通过添加可选的 TLP 前缀来扩展 Steering Tag 位。当 TLP 携带一个或多个前缀时，头部通过设置 Format 字段的最高有效位来报告这一点，如图 20-19 所示。

图 20-19：TPH 前缀指示

20.3.3 IDO（基于 ID 的排序）

事务排序规则对正确的流量流动很重要，但在某些情况下并不需要严格排序，而放宽排序可以改善延迟。特别是，来自不同请求者的 TLP 之间通常不太可能存在依赖关系。因此，基于 ID 的排序（IDO，ID-based Ordering）允许软件启用这些 TLP 的重新排序，以提升性能。该操作的详细说明见第 301 页“基于 ID 的排序（IDO）”一节。

20.3.4 ARI（替代路由 ID 解释）

该可选功能的动机是增加端点可用的功能编号数量。设备编号在 PCI 这样的共享总线架构中很有用，但在点对点架构中通常并不需要。因此，规范编写者选择允许设备以不同方式解释 ID 路由命令的目标。具体做法是将设备编号始终定义为 0，然后允许功能编号使用 ID 中原本属于设备编号的 5 个比特位。这样，设备编号实际上消失，功能编号扩展为 8 位。使用 ARI 的 TLP，其目标设备必须先启用 ARI 识别能力，软件才能使用该特性；但路径上的路由元件不需要了解 ARI，因为它们只查看总线号来决定路由。

20.4 电源管理改进

以下四项新增内容增强了系统有效管理电源的能力。这些内容均已在第 16 章“电源管理”中介绍。

20.4.1 DPA（动态电源分配）

一组新的扩展配置寄存器定义了 D0 以下最多 32 个子状态。这使软件能够更方便地改变设备电源状态，而无需承受一路进入 D1 设备电源状态所带来的延迟开销。更多信息请参见第 714 页“动态电源分配（DPA）”一节。

20.4.2 LTR（延迟容忍度报告）

允许端点报告它们能够容忍的请求响应延迟，使系统软件能够更好地选择系统响应时间和睡眠状态。更多信息请参见第 784 页“LTR（延迟容忍度报告）”一节。

20.4.3 OBFF（优化缓冲区刷新与填充）

类似地，允许系统报告端点应当或不应当发起 DMA 或中断流量的首选时间段，有助于协调系统睡眠时间并改善电源管理。更多信息请参见第 776 页“OBFF（优化缓冲区刷新与填充）”一节。

20.4.4 ASPM 选项

该变更只是允许设备在需要时选择不支持任何 ASPM 链路电源管理。在之前的规范版本中，支持 L0s 是强制要求，但现在变为可选。

20.5 配置改进

新增了少量配置寄存器，以提升软件对设备的可见性和控制能力。

20.5.1 内部错误报告

该机制旨在为交换机等没有设备驱动程序来处理内部问题的设备提供一种标准化的内部问题报告方式。同时，它还增加了在错误发生时跟踪多个 TLP 头部的能力，而不是像以前那样只能跟踪一个。该主题在错误处理章节的“内部错误”一节中已有讨论，见第 667 页。

20.5.2 可调整大小的 BAR

这组新的扩展配置寄存器允许使用大量本地内存的设备报告自己是否能够使用较小的内存量；如果可以，也可以报告哪些大小是可接受的。能够识别这些寄存器的软件可以找到图 20-20 所示的新寄存器，并根据系统内存和其他设备之间的竞争需求，对其进行编程，为平台分配合适的内存大小。

使用这些寄存器时需要遵循以下规则：

1. 为避免混淆，只有在命令寄存器中的 Memory Enable 位已清零时，才应改变 BAR 大小。
2. 规范强烈建议，功能不要声明超出其有效使用范围的 BAR 大小。
3. 为确保最佳性能，软件应分配系统能够支持的最大 BAR 大小。

图 20-20：可调整大小的 BAR 寄存器

20.5.2.1 能力寄存器

该寄存器仅用于报告哪些 BAR 大小适用于此功能。位 4 至位 23 用于此目的，其含义如下：

• 位 4：该功能支持 1 MB BAR 大小。
• 位 5：该功能支持 2 MB BAR 大小。
• 位 6：该功能支持 4 MB BAR 大小。
• ……
• 位 23：该功能支持 512 GB BAR 大小。

图 20-21：可调整大小 BAR 能力寄存器

20.5.2.2 控制寄存器

该寄存器中的 BAR Index 字段指示此大小对应哪一个 BAR，可能值为 0 至 5。Number of Resizable BARs 字段仅在第 0 组控制寄存器中定义，在其他控制寄存器中为保留字段。该字段用于说明 6 个可能的 BAR 中，有多少个实际具有可调整大小。最后，BAR Size 字段由软件编程，用于指定 BAR Index 字段所指示的 BAR 所需大小，其编码为：0 = 1MB、1 = 2MB、2 = 4MB，依此类推，直到 19 = 512GB。

图 20-22：可调整大小 BAR 控制寄存器

一旦可调整大小的值被编程，枚举软件就能够像往常一样工作：向每个 BAR 写入全 1 再读回时，将报告所选择的大小。需要注意的是，如果大小值发生改变，BAR 的内容将丢失；如果该 BAR 之前已经设置过，则需要重新编程。图 20-23 突出显示了 Type 0 配置头空间中的 BAR 寄存器。

图 20-23：Type 0 配置头中的 BAR

20.5.3 简化排序表

该变更通过减少表中的条目数量来简化事务排序表。本质上，它不再区分读取操作的完成报文与非已发布写入操作的完成报文。这样做的动机是减少需要测试的案例数量。更多详情请参见第 288 页“简化排序规则表”一节。